home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 1998 November / Freeware November 1998.img / dist / fw_emacs.idb / usr / freeware / info / gnus-8.z / gnus-8 (.txt)
GNU Info File  |  1998-10-27  |  50KB  |  948 lines
  1. This is Info file ../info/gnus, produced by Makeinfo-1.63 from the
  2. input file gnus.texi.
  3.    This file documents Gnus, the GNU Emacs newsreader.
  4.    Copyright (C) 1995,96 Free Software Foundation, Inc.
  5.    Permission is granted to make and distribute verbatim copies of this
  6. manual provided the copyright notice and this permission notice are
  7. preserved on all copies.
  8.    Permission is granted to copy and distribute modified versions of
  9. this manual under the conditions for verbatim copying, provided also
  10. that the entire resulting derived work is distributed under the terms
  11. of a permission notice identical to this one.
  12.    Permission is granted to copy and distribute translations of this
  13. manual into another language, under the above conditions for modified
  14. versions.
  15. File: gnus,  Node: Terminology,  Next: Customization,  Prev: History,  Up: Appendices
  16. Terminology
  17. ===========
  18. "news"
  19.      This is what you are supposed to use this thing for--reading news.
  20.      News is generally fetched from a nearby NNTP server, and is
  21.      generally publicly available to everybody.  If you post news, the
  22.      entire world is likely to read just what you have written, and
  23.      they'll all snigger mischievously.  Behind your back.
  24. "mail"
  25.      Everything that's delivered to you personally is mail.  Some
  26.      news/mail readers (like Gnus) blur the distinction between mail
  27.      and news, but there is a difference.  Mail is private.  News is
  28.      public.  Mailing is not posting, and replying is not following up.
  29. "reply"
  30.      Send a mail to the person who has written what you are reading.
  31. "follow up"
  32.      Post an article to the current newsgroup responding to the article
  33.      you are reading.
  34. "backend"
  35.      Gnus gets fed articles from a number of backends, both news and
  36.      mail backends.  Gnus does not handle the underlying media, so to
  37.      speak--this is all done by the backends.
  38. "native"
  39.      Gnus will always use one method (and backend) as the "native", or
  40.      default, way of getting news.
  41. "foreign"
  42.      You can also have any number of foreign groups active at the same
  43.      time.  These are groups that use different backends for getting
  44.      news.
  45. "secondary"
  46.      Secondary backends are somewhere half-way between being native and
  47.      being foreign, but they mostly act like they are native.
  48. "article"
  49.      A nessage that has been posted as news.
  50. "mail message"
  51.      A message that has been mailed.
  52. "message"
  53.      A mail message or news article
  54. "head"
  55.      The top part of a message, where administrative information (etc.)
  56.      is put.
  57. "body"
  58.      The rest of an article.  Everything that is not in the head is in
  59.      the body.
  60. "header"
  61.      A line from the head of an article.
  62. "headers"
  63.      A collection of such lines, or a collection of heads.  Or even a
  64.      collection of NOV lines.
  65. "NOV"
  66.      When Gnus enters a group, it asks the backend for the headers of
  67.      all unread articles in the group.  Most servers support the News
  68.      OverView format, which is more compact and much faster to read and
  69.      parse than the normal HEAD format.
  70. "level"
  71.      Each group is subscribed at some "level" or other (1-9).  The ones
  72.      that have a lower level are "more" subscribed than the groups with
  73.      a higher level.  In fact, groups on levels 1-5 are considered
  74.      "subscribed"; 6-7 are "unsubscribed"; 8 are "zombies"; and 9 are
  75.      "killed".  Commands for listing groups and scanning for new
  76.      articles will all use the numeric prefix as "working level".
  77. "killed groups"
  78.      No information on killed groups is stored or updated, which makes
  79.      killed groups much easier to handle than subscribed groups.
  80. "zombie groups"
  81.      Just like killed groups, only slightly less dead.
  82. "active file"
  83.      The news server has to keep track of what articles it carries, and
  84.      what groups exist.  All this information in stored in the active
  85.      file, which is rather large, as you might surmise.
  86. "bogus groups"
  87.      A group that exists in the `.newsrc' file, but isn't known to the
  88.      server (i. e.,  it isn't in the active file), is a *bogus group*.
  89.      This means that the group probably doesn't exist (any more).
  90. "server"
  91.      A machine than one can connect to and get news (or mail) from.
  92. "select method"
  93.      A structure that specifies the backend, the server and the virtual
  94.      server parameters.
  95. "virtual server"
  96.      A named select method.  Since a select methods defines all there
  97.      is to know about connecting to a (physical) server, taking the who
  98.      things as a whole is a virtual server.
  99. File: gnus,  Node: Customization,  Next: Troubleshooting,  Prev: Terminology,  Up: Appendices
  100. Customization
  101. =============
  102.    All variables are properly documented elsewhere in this manual.  This
  103. section is designed to give general pointers on how to customize Gnus
  104. for some quite common situations.
  105. * Menu:
  106. * Slow/Expensive Connection:: You run a local Emacs and get the news elsewhere.
  107. * Slow Terminal Connection::  You run a remote Emacs.
  108. * Little Disk Space::         You feel that having large setup files is icky.
  109. * Slow Machine::              You feel like buying a faster machine.
  110. File: gnus,  Node: Slow/Expensive Connection,  Next: Slow Terminal Connection,  Up: Customization
  111. Slow/Expensive NNTP Connection
  112. ------------------------------
  113.    If you run Emacs on a machine locally, and get your news from a
  114. machine over some very thin strings, you want to cut down on the amount
  115. of data Gnus has to get from the NNTP server.
  116. `gnus-read-active-file'
  117.      Set this to `nil', which will inhibit Gnus from requesting the
  118.      entire active file from the server.  This file is often v.  large.
  119.      You also have to set `gnus-check-new-news' and
  120.      `gnus-check-bogus-newsgroups' to `nil' to make sure that Gnus
  121.      doesn't suddenly decide to fetch the active file anyway.
  122. `gnus-nov-is-evil'
  123.      This one has to be `nil'.  If not, grabbing article headers from
  124.      the NNTP server will not be very fast.  Not all NNTP servers
  125.      support XOVER; Gnus will detect this by itself.
  126. File: gnus,  Node: Slow Terminal Connection,  Next: Little Disk Space,  Prev: Slow/Expensive Connection,  Up: Customization
  127. Slow Terminal Connection
  128. ------------------------
  129.    Let's say you use your home computer for dialing up the system that
  130. runs Emacs and Gnus.  If your modem is slow, you want to reduce the
  131. amount of data that is sent over the wires as much as possible.
  132. `gnus-auto-center-summary'
  133.      Set this to `nil' to inhibit Gnus from re-centering the summary
  134.      buffer all the time.  If it is `vertical', do only vertical
  135.      re-centering.  If it is neither `nil' nor `vertical', do both
  136.      horizontal and vertical recentering.
  137. `gnus-visible-headers'
  138.      Cut down on the headers that are included in the articles to the
  139.      minimum.  You can, in fact, make do without them altogether--most
  140.      of the useful data is in the summary buffer, anyway.  Set this
  141.      variable to `^NEVVVVER' or `From:', or whatever you feel you need.
  142. `gnus-article-display-hook'
  143.      Set this hook to all the available hiding commands:
  144.           (setq gnus-article-display-hook
  145.                 '(gnus-article-hide-headers gnus-article-hide-signature
  146.                   gnus-article-hide-citation))
  147. `gnus-use-full-window'
  148.      By setting this to `nil', you can make all the windows smaller.
  149.      While this doesn't really cut down much generally, it means that
  150.      you have to see smaller portions of articles before deciding that
  151.      you didn't want to read them anyway.
  152. `gnus-thread-hide-subtree'
  153.      If this is non-`nil', all threads in the summary buffer will be
  154.      hidden initially.
  155. `gnus-updated-mode-lines'
  156.      If this is `nil', Gnus will not put information in the buffer mode
  157.      lines, which might save some time.
  158. File: gnus,  Node: Little Disk Space,  Next: Slow Machine,  Prev: Slow Terminal Connection,  Up: Customization
  159. Little Disk Space
  160. -----------------
  161.    The startup files can get rather large, so you may want to cut their
  162. sizes a bit if you are running out of space.
  163. `gnus-save-newsrc-file'
  164.      If this is `nil', Gnus will never save `.newsrc'--it will only
  165.      save `.newsrc.eld'.  This means that you will not be able to use
  166.      any other newsreaders than Gnus.  This variable is `t' by default.
  167. `gnus-save-killed-list'
  168.      If this is `nil', Gnus will not save the list of dead groups.  You
  169.      should also set `gnus-check-new-newsgroups' to `ask-server' and
  170.      `gnus-check-bogus-newsgroups' to `nil' if you set this variable to
  171.      `nil'.  This variable is `t' by default.
  172. File: gnus,  Node: Slow Machine,  Prev: Little Disk Space,  Up: Customization
  173. Slow Machine
  174. ------------
  175.    If you have a slow machine, or are just really impatient, there are a
  176. few things you can do to make Gnus run faster.
  177.    Set`gnus-check-new-newsgroups' and `gnus-check-bogus-newsgroups' to
  178. `nil' to make startup faster.
  179.    Set `gnus-show-threads', `gnus-use-cross-reference' and
  180. `gnus-nov-is-evil' to `nil' to make entering and exiting the summary
  181. buffer faster.
  182.    Set `gnus-article-display-hook' to `nil' to make article processing
  183. a bit faster.
  184. File: gnus,  Node: Troubleshooting,  Next: A Programmers Guide to Gnus,  Prev: Customization,  Up: Appendices
  185. Troubleshooting
  186. ===============
  187.    Gnus works *so* well straight out of the box--I can't imagine any
  188. problems, really.
  189.    Ahem.
  190.   1. Make sure your computer is switched on.
  191.   2. Make sure that you really load the current Gnus version.  If you
  192.      have been running GNUS, you need to exit Emacs and start it up
  193.      again before Gnus will work.
  194.   3. Try doing an `M-x gnus-version'.  If you get something that looks
  195.      like `Gnus v5.46; nntp 4.0' you have the right files loaded.  If,
  196.      on the other hand, you get something like `NNTP 3.x' or `nntp
  197.      flee', you have some old `.el' files lying around.  Delete these.
  198.   4. Read the help group (`G h' in the group buffer) for a FAQ and a
  199.      how-to.
  200.    If all else fails, report the problem as a bug.
  201.    If you find a bug in Gnus, you can report it with the `M-x gnus-bug'
  202. command. `M-x set-variable RET debug-on-error RET t RET', and send me
  203. the backtrace.  I will fix bugs, but I can only fix them if you send me
  204. a precise description as to how to reproduce the bug.
  205.    You really can never be too detailed in a bug report.  Always use the
  206. `M-x gnus-bug' command when you make bug reports, even if it creates a
  207. 10Kb mail each time you use it, and even if you have sent me your
  208. environment 500 times before.  I don't care.  I want the full info each
  209. time.
  210.    It is also important to remember that I have no memory whatsoever.
  211. If you send a bug report, and I send you a reply, and then you send back
  212. just "No, it's not! Moron!", I will have no idea what you are insulting
  213. me about.  Always over-explain everything.  It's much easier for all of
  214. us--if I don't have all the information I need, I will just mail you
  215. and ask for more info, and everything takes more time.
  216.    If the problem you're seeing is very visual, and you can't quite
  217. explain it, copy the Emacs window to a file (with `xwd', for instance),
  218. put it somewhere it can be reached, and include the URL of the picture
  219. in the bug report.a
  220.    If you just need help, you are better off asking on
  221. `gnu.emacs.gnus'.  I'm not very helpful.
  222.    You can also ask on the ding mailing list--`ding@ifi.uio.no'.  Write
  223. to `ding-request@ifi.uio.no' to subscribe.
  224. File: gnus,  Node: A Programmers Guide to Gnus,  Next: Emacs for Heathens,  Prev: Troubleshooting,  Up: Appendices
  225. A Programmer's Guide to Gnus
  226. ============================
  227.    It is my hope that other people will figure out smart stuff that Gnus
  228. can do, and that other people will write those smart things as well.  To
  229. facilitate that I thought it would be a good idea to describe the inner
  230. workings of Gnus.  And some of the not-so-inner workings, while I'm at
  231.    You can never expect the internals of a program not to change, but I
  232. will be defining (in some details) the interface between Gnus and its
  233. backends (this is written in stone), the format of the score files
  234. (ditto), data structures (some are less likely to change than others)
  235. and general method of operations.
  236. * Menu:
  237. * Backend Interface::        How Gnus communicates with the servers.
  238. * Score File Syntax::        A BNF definition of the score file standard.
  239. * Headers::                  How Gnus stores headers internally.
  240. * Ranges::                   A handy format for storing mucho numbers.
  241. * Group Info::               The group info format.
  242. * Emacs/XEmacs Code::        Gnus can be run under all modern Emacsen.
  243. * Various File Formats::     Formats of files that Gnus use.
  244. File: gnus,  Node: Backend Interface,  Next: Score File Syntax,  Up: A Programmers Guide to Gnus
  245. Backend Interface
  246. -----------------
  247.    Gnus doesn't know anything about NNTP, spools, mail or virtual
  248. groups.  It only knows how to talk to "virtual servers".  A virtual
  249. server is a "backend" and some "backend variables".  As examples of the
  250. first, we have `nntp', `nnspool' and `nnmbox'.  As examples of the
  251. latter we have `nntp-port-number' and `nnmbox-directory'.
  252.    When Gnus asks for information from a backend--say `nntp'--on
  253. something, it will normally include a virtual server name in the
  254. function parameters.  (If not, the backend should use the "current"
  255. virtual server.)  For instance, `nntp-request-list' takes a virtual
  256. server as its only (optional) parameter.  If this virtual server hasn't
  257. been opened, the function should fail.
  258.    Note that a virtual server name has no relation to some physical
  259. server name.  Take this example:
  260.      (nntp "odd-one"
  261.            (nntp-address "ifi.uio.no")
  262.            (nntp-port-number 4324))
  263.    Here the virtual server name is `odd-one' while the name of the
  264. physical server is `ifi.uio.no'.
  265.    The backends should be able to switch between several virtual
  266. servers.  The standard backends implement this by keeping an alist of
  267. virtual server environments that it pulls down/pushes up when needed.
  268.    There are two groups of interface functions: "required functions",
  269. which must be present, and "optional functions", which Gnus will always
  270. check whether are present before attempting to call.
  271.    All these functions are expected to return data in the buffer
  272. `nntp-server-buffer' (` *nntpd*'), which is somewhat unfortunately
  273. named, but we'll have to live with it.  When I talk about "resulting
  274. data", I always refer to the data in that buffer.  When I talk about
  275. "return value", I talk about the function value returned by the
  276. function call.
  277.    Some backends could be said to be "server-forming" backends, and
  278. some might be said to not be.  The latter are backends that generally
  279. only operate on one group at a time, and have no concept of "server" -
  280. they have a group, and they deliver info on that group and nothing more.
  281.    In the examples and definitions I will refer to the imaginary backend
  282. `nnchoke'.
  283. * Menu:
  284. * Required Backend Functions::        Functions that must be implemented.
  285. * Optional Backend Functions::        Functions that need not be implemented.
  286. * Writing New Backends::              Extending old backends.
  287. File: gnus,  Node: Required Backend Functions,  Next: Optional Backend Functions,  Up: Backend Interface
  288. Required Backend Functions
  289. ..........................
  290. `(nnchoke-retrieve-headers ARTICLES &optional GROUP SERVER FETCH-OLD)'
  291.      ARTICLES is either a range of article numbers or a list of
  292.      `Message-ID's.  Current backends do not fully support either--only
  293.      sequences (lists) of article numbers, and most backends do not
  294.      support retrieval of `Message-ID's.  But they should try for both.
  295.      The result data should either be HEADs or NOV lines, and the result
  296.      value should either be `headers' or `nov' to reflect this.  This
  297.      might later be expanded to `various', which will be a mixture of
  298.      HEADs and NOV lines, but this is currently not supported by Gnus.
  299.      If FETCH-OLD is non-`nil' it says to try to fetch "extra headers,
  300.      in some meaning of the word.  This is generally done by fetching
  301.      (at most) FETCH-OLD extra headers less than the smallest article
  302.      number in `articles', and fill in the gaps as well.  The presence
  303.      of this parameter can be ignored if the backend finds it
  304.      cumbersome to follow the request.  If this is non-`nil' and not a
  305.      number, do maximum fetches.
  306.      Here's an example HEAD:
  307.           221 1056 Article retrieved.
  308.           Path: ifi.uio.no!sturles
  309.           From: sturles@ifi.uio.no (Sturle Sunde)
  310.           Newsgroups: ifi.discussion
  311.           Subject: Re: Something very droll
  312.           Date: 27 Oct 1994 14:02:57 +0100
  313.           Organization: Dept. of Informatics, University of Oslo, Norway
  314.           Lines: 26
  315.           Message-ID: <38o8e1$a0o@holmenkollen.ifi.uio.no>
  316.           References: <38jdmq$4qu@visbur.ifi.uio.no>
  317.           NNTP-Posting-Host: holmenkollen.ifi.uio.no
  318.           .
  319.      So a `headers' return value would imply that there's a number of
  320.      these in the data buffer.
  321.      Here's a BNF definition of such a buffer:
  322.           headers        = *head
  323.           head           = error / valid-head
  324.           error-message  = [ "4" / "5" ] 2number " " <error message> eol
  325.           valid-head     = valid-message *header "." eol
  326.           valid-message  = "221 " <number> " Article retrieved." eol
  327.           header         = <text> eol
  328.      If the return value is `nov', the data buffer should contain
  329.      "network overview database" lines.  These are basically fields
  330.      separated by tabs.
  331.           nov-buffer = *nov-line
  332.           nov-line   = 8*9 [ field <TAB> ] eol
  333.           field      = <text except TAB>
  334.      For a closer explanation what should be in those fields, *note
  335.      Headers::..
  336. `(nnchoke-open-server SERVER &optional DEFINITIONS)'
  337.      SERVER is here the virtual server name.  DEFINITIONS is a list of
  338.      `(VARIABLE VALUE)' pairs that defines this virtual server.
  339.      If the server can't be opened, no error should be signaled.  The
  340.      backend may then choose to refuse further attempts at connecting
  341.      to this server.  In fact, it should do so.
  342.      If the server is opened already, this function should return a
  343.      non-`nil' value.  There should be no data returned.
  344. `(nnchoke-close-server &optional SERVER)'
  345.      Close connection to SERVER and free all resources connected to it.
  346.      Return `nil' if the server couldn't be closed for some reason.
  347.      There should be no data returned.
  348. `(nnchoke-request-close)'
  349.      Close connection to all servers and free all resources that the
  350.      backend have reserved.  All buffers that have been created by that
  351.      backend should be killed.  (Not the `nntp-server-buffer', though.)
  352.      This function is generally only called when Gnus is shutting down.
  353.      There should be no data returned.
  354. `(nnchoke-server-opened &optional SERVER)'
  355.      If SERVER is the current virtual server, and the connection to the
  356.      physical server is alive, then this function should return a
  357.      non-`nil' vlue.  This function should under no circumstances
  358.      attempt to reconnect to a server that is has lost connection to.
  359.      There should be no data returned.
  360. `(nnchoke-status-message &optional SERVER)'
  361.      This function should return the last error message from SERVER.
  362.      There should be no data returned.
  363. `(nnchoke-request-article ARTICLE &optional GROUP SERVER TO-BUFFER)'
  364.      The result data from this function should be the article specified
  365.      by ARTICLE.  This might either be a `Message-ID' or a number.  It
  366.      is optional whether to implement retrieval by `Message-ID', but it
  367.      would be nice if that were possible.
  368.      If TO-BUFFER is non-`nil', the result data should be returned in
  369.      this buffer instead of the normal data buffer.  This is to make it
  370.      possible to avoid copying large amounts of data from one buffer to
  371.      another, and Gnus mainly request articles to be inserted directly
  372.      into its article buffer.
  373.      If it is at all possible, this function should return a cons cell
  374.      where the car is the group name the article was fetched from, and
  375.      the cdr is the article number.  This will enable Gnus to find out
  376.      what the real group and article numbers are when fetching articles
  377.      by `Message-ID'.  If this isn't possible, `t' should be returned
  378.      on successful article retrievement.
  379. `(nnchoke-open-group GROUP &optional SERVER)'
  380.      Make GROUP the current group.
  381.      There should be no data returned by this function.
  382. `(nnchoke-request-group GROUP &optional SERVER)'
  383.      Get data on GROUP.  This function also has the side effect of
  384.      making GROUP the current group.
  385.      Here's an example of some result data and a definition of the same:
  386.           211 56 1000 1059 ifi.discussion
  387.      The first number is the status, which should be `211'.  Next is the
  388.      total number of articles in the group, the lowest article number,
  389.      the highest article number, and finally the group name.  Note that
  390.      the total number of articles may be less than one might think
  391.      while just considering the highest and lowest article numbers, but
  392.      some articles may have been canceled.  Gnus just discards the
  393.      total-number, so whether one should take the bother to generate it
  394.      properly (if that is a problem) is left as an exercise to the
  395.      reader.
  396.           group-status = [ error / info ] eol
  397.           error        = [ "4" / "5" ] 2<number> " " <Error message>
  398.           info         = "211 " 3* [ <number> " " ] <string>
  399. `(nnchoke-close-group GROUP &optional SERVER)'
  400.      Close GROUP and free any resources connected to it.  This will be
  401.      a no-op on most backends.
  402.      There should be no data returned.
  403. `(nnchoke-request-list &optional SERVER)'
  404.      Return a list of all groups available on SERVER.  And that means
  405.      *all*.
  406.      Here's an example from a server that only carries two groups:
  407.           ifi.test 0000002200 0000002000 y
  408.           ifi.discussion 3324 3300 n
  409.      On each line we have a group name, then the highest article number
  410.      in that group, the lowest article number, and finally a flag.
  411.           active-file = *active-line
  412.           active-line = name " " <number> " " <number> " " flags eol
  413.           name        = <string>
  414.           flags       = "n" / "y" / "m" / "x" / "j" / "=" name
  415.      The flag says whether the group is read-only (`n'), is moderated
  416.      (`m'), is dead (`x'), is aliased to some other group
  417.      (`=other-group' or none of the above (`y').
  418. `(nnchoke-request-post &optional SERVER)'
  419.      This function should post the current buffer.  It might return
  420.      whether the posting was successful or not, but that's not
  421.      required.  If, for instance, the posting is done asynchronously,
  422.      it has generally not been completed by the time this function
  423.      concludes.  In that case, this function should set up some kind of
  424.      sentinel to beep the user loud and clear if the posting could not
  425.      be completed.
  426.      There should be no result data from this function.
  427. File: gnus,  Node: Optional Backend Functions,  Next: Writing New Backends,  Prev: Required Backend Functions,  Up: Backend Interface
  428. Optional Backend Functions
  429. ..........................
  430. `(nnchoke-retrieve-groups GROUPS &optional SERVER)'
  431.      GROUPS is a list of groups, and this function should request data
  432.      on all those groups.  How it does it is of no concern to Gnus, but
  433.      it should attempt to do this in a speedy fashion.
  434.      The return value of this function can be either `active' or
  435.      `group', which says what the format of the result data is.  The
  436.      former is in the same format as the data from
  437.      `nnchoke-request-list', while the latter is a buffer full of lines
  438.      in the same format as `nnchoke-request-group' gives.
  439.           group-buffer = *active-line / *group-status
  440. `(nnchoke-request-update-info GROUP INFO &optional SERVER)'
  441.      A Gnus group info (*note Group Info::.) is handed to the backend
  442.      for alterations.  This comes in handy if the backend really
  443.      carries all the information (as is the case with virtual an imap
  444.      groups).  This function may alter the info in any manner it sees
  445.      fit, and should return the (altered) group info.  This function
  446.      may alter the group info destructively, so no copying is needed
  447.      before boogeying.
  448.      There should be no result data from this function.
  449. `(nnchoke-request-type GROUP &optional ARTICLE)'
  450.      When the user issues commands for "sending news" (`F' in the
  451.      summary buffer, for instance), Gnus has to know whether the
  452.      article the user is following up is news or mail.  This function
  453.      should return `news' if ARTICLE in GROUP is news, `mail' if it is
  454.      mail and `unknown' if the type can't be decided.  (The ARTICLE
  455.      parameter is necessary in `nnvirtual' groups which might very well
  456.      combine mail groups and news groups.)
  457.      There should be no result data from this function.
  458. `(nnchoke-request-update-mark GROUP ARTICLE MARK)'
  459.      If the user tries to set a mark that the backend doesn't like, this
  460.      function may change the mark.  Gnus will use whatever this function
  461.      returns as the mark for ARTICLE instead of the original MARK.  If
  462.      the backend doesn't care, it must return the original MARK, and
  463.      not `nil' or any other type of garbage.
  464.      The only use for this that I can see is what `nnvirtual' does with
  465.      it--if a component group is auto-expirable, marking an article as
  466.      read in the virtual group should result in the article being
  467.      marked as expirable.
  468.      There should be no result data from this function.
  469. `(nnchoke-request-scan &optional GROUP SERVER)'
  470.      This function may be called at any time (by Gnus or anything else)
  471.      to request that the backend check for incoming articles, in one
  472.      way or another.  A mail backend will typically read the spool file
  473.      or query the POP server when this function is invoked.  The GROUP
  474.      doesn't have to be heeded--if the backend decides that it is too
  475.      much work just scanning for a single group, it may do a total scan
  476.      of all groups.  It would be nice, however, to keep things local if
  477.      that's practical.
  478.      There should be no result data from this function.
  479. `(nnchoke-request-asynchronous GROUP &optional SERVER ARTICLES)'
  480.      This is a request to fetch articles asynchronously later.
  481.      ARTICLES is an alist of (ARTICLE-NUMBER LINE-NUMBER).  One would
  482.      generally expect that if one later fetches article number 4, for
  483.      instance, some sort of asynchronous fetching of the articles after
  484.      4 (which might be 5, 6, 7 or 11, 3, 909 depending on the order in
  485.      that alist) would be fetched asynchronously, but that is left up
  486.      to the backend.  Gnus doesn't care.
  487.      There should be no result data from this function.
  488. `(nnchoke-request-group-description GROUP &optional SERVER)'
  489.      The result data from this function should be a description of
  490.      GROUP.
  491.           description-line = name <TAB> description eol
  492.           name             = <string>
  493.           description      = <text>
  494. `(nnchoke-request-list-newsgroups &optional SERVER)'
  495.      The result data from this function should be the description of all
  496.      groups available on the server.
  497.           description-buffer = *description-line
  498. `(nnchoke-request-newgroups DATE &optional SERVER)'
  499.      The result data from this function should be all groups that were
  500.      created after `date', which is in normal human-readable date
  501.      format.  The data should be in the active buffer format.
  502. `(nnchoke-request-create-group GROUP &optional SERVER)'
  503.      This function should create an empty group with name GROUP.
  504.      There should be no return data.
  505. `(nnchoke-request-expire-articles ARTICLES &optional GROUP SERVER FORCE)'
  506.      This function should run the expiry process on all articles in the
  507.      ARTICLES range (which is currently a simple list of article
  508.      numbers.)  It is left up to the backend to decide how old articles
  509.      should be before they are removed by this function.  If FORCE is
  510.      non-`nil', all ARTICLES should be deleted, no matter how new they
  511.      are.
  512.      This function should return a list of articles that it did not/was
  513.      not able to delete.
  514.      There should be no result data returned.
  515. `(nnchoke-request-move-article ARTICLE GROUP SERVER ACCEPT-FORM'
  516.      &optional LAST)
  517.      This function should move ARTICLE (which is a number) from GROUP
  518.      by calling ACCEPT-FORM.
  519.      This function should ready the article in question for moving by
  520.      removing any header lines it has added to the article, and
  521.      generally should "tidy up" the article.  Then it should `eval'
  522.      ACCEPT-FORM in the buffer where the "tidy" article is.  This will
  523.      do the actual copying.  If this `eval' returns a non-`nil' value,
  524.      the article should be removed.
  525.      If LAST is `nil', that means that there is a high likelihood that
  526.      there will be more requests issued shortly, so that allows some
  527.      optimizations.
  528.      The function should return a cons where the car is the group name
  529.      and the cdr is the article number that the article was entered as.
  530.      There should be no data returned.
  531. `(nnchoke-request-accept-article GROUP &optional SERVER LAST)'
  532.      This function takes the current buffer and inserts it into GROUP.
  533.      If LAST in `nil', that means that there will be more calls to this
  534.      function in short order.
  535.      The function should return a cons where the car is the group name
  536.      and the cdr is the article number that the article was entered as.
  537.      There should be no data returned.
  538. `(nnchoke-request-replace-article ARTICLE GROUP BUFFER)'
  539.      This function should remove ARTICLE (which is a number) from GROUP
  540.      and insert BUFFER there instead.
  541.      There should be no data returned.
  542. `(nnchoke-request-delete-group GROUP FORCE &optional SERVER)'
  543.      This function should delete GROUP.  If FORCE, it should really
  544.      delete all the articles in the group, and then delete the group
  545.      itself.  (If there is such a thing as "the group itself".)
  546.      There should be no data returned.
  547. `(nnchoke-request-rename-group GROUP NEW-NAME &optional SERVER)'
  548.      This function should rename GROUP into NEW-NAME.  All articles
  549.      that are in GROUP should move to NEW-NAME.
  550.      There should be no data returned.
  551. File: gnus,  Node: Writing New Backends,  Prev: Optional Backend Functions,  Up: Backend Interface
  552. Writing New Backends
  553. ....................
  554.    The various backends share many similarities.  `nnml' is just like
  555. `nnspool', but it allows you to edit the articles on the server.
  556. `nnmh' is just like `nnml', but it doesn't use an active file, and it
  557. doesn't maintain overview databases.  `nndir' is just like `nnml', but
  558. it has no concept of "groups", and it doesn't allow editing articles.
  559.    It would make sense if it were possible to "inherit" functions from
  560. backends when writing new backends.  And, indeed, you can do that if you
  561. want to.  (You don't have to if you don't want to, of course.)
  562.    All the backends declare their public variables and functions by
  563. using a package called `nnoo'.
  564.    To inherit functions from other backends (and allow other backends to
  565. inherit functions from the current backend), you should use the
  566. following macros: following.
  567. `nnoo-declare'
  568.      This macro declares the first parameter to be a child of the
  569.      subsequent parameters.  For instance:
  570.           (nnoo-declare nndir
  571.             nnml nnmh)
  572.      `nndir' has here declared that it intends to inherit functions from
  573.      both `nnml' and `nnmh'.
  574. `defvoo'
  575.      This macro is equivalent to `defvar', but registers the variable as
  576.      a public server variable.  Most state-oriented variables should be
  577.      declared with `defvoo' instead of `defvar'.
  578.      In addition to the normal `defvar' parameters, it takes a list of
  579.      variables in the parent backends to map the variable to when
  580.      executing a function in those backends.
  581.           (defvoo nndir-directory nil
  582.             "Where nndir will look for groups."
  583.             nnml-current-directory nnmh-current-directory)
  584.      This means that `nnml-current-directory' will be set to
  585.      `nndir-directory' when an `nnml' function is called on behalf of
  586.      `nndir'.  (The same with `nnmh'.)
  587. `nnoo-define-basics'
  588.      This macro defines some common functions that almost all backends
  589.      should have.
  590.           (nnoo-define-basics nndir)
  591. `deffoo'
  592.      This macro is just like `defun' and takes the same parameters.  In
  593.      addition to doing the normal `defun' things, it registers the
  594.      function as being public so that other backends can inherit it.
  595. `nnoo-map-functions'
  596.      This macro allows mapping of functions from the current backend to
  597.      functions from the parent backends.
  598.           (nnoo-map-functions nndir
  599.             (nnml-retrieve-headers 0 nndir-current-group 0 0)
  600.             (nnmh-request-article 0 nndir-current-group 0 0))
  601.      This means that when `nndir-retrieve-headers' is called, the first,
  602.      third, and fourth parameters will be passed on to
  603.      `nnml-retrieve-headers', while the second parameter is set to the
  604.      value of `nndir-current-group'.
  605. `nnoo-import'
  606.      This macro allows importing functions from backends.  It should be
  607.      the last thing in the source file, since it will only define
  608.      functions that haven't already been defined.
  609.           (nnoo-import nndir
  610.             (nnmh
  611.              nnmh-request-list
  612.              nnmh-request-newgroups)
  613.             (nnml))
  614.      This means that calls to `nndir-request-list' should just be passed
  615.      on to `nnmh-request-list', while all public functions from `nnml'
  616.      that haven't been defined in `nndir' yet should be defined now.
  617.    Below is a slightly shortened version of the `nndir' backend.
  618.      ;;; nndir.el --- single directory newsgroup access for Gnus
  619.      ;; Copyright (C) 1995,96 Free Software Foundation, Inc.
  620.      
  621.      ;;; Code:
  622.      
  623.      (require 'nnheader)
  624.      (require 'nnmh)
  625.      (require 'nnml)
  626.      (require 'nnoo)
  627.      (eval-when-compile (require 'cl))
  628.      
  629.      (nnoo-declare nndir
  630.        nnml nnmh)
  631.      
  632.      (defvoo nndir-directory nil
  633.        "Where nndir will look for groups."
  634.        nnml-current-directory nnmh-current-directory)
  635.      
  636.      (defvoo nndir-nov-is-evil nil
  637.        "*Non-nil means that nndir will never retrieve NOV headers."
  638.        nnml-nov-is-evil)
  639.      
  640.      (defvoo nndir-current-group "" nil nnml-current-group nnmh-current-group)
  641.      (defvoo nndir-top-directory nil nil nnml-directory nnmh-directory)
  642.      (defvoo nndir-get-new-mail nil nil nnml-get-new-mail nnmh-get-new-mail)
  643.      
  644.      (defvoo nndir-status-string "" nil nnmh-status-string)
  645.      (defconst nndir-version "nndir 1.0")
  646.      
  647.      ;;; Interface functions.
  648.      
  649.      (nnoo-define-basics nndir)
  650.      
  651.      (deffoo nndir-open-server (server &optional defs)
  652.        (setq nndir-directory
  653.          (or (cadr (assq 'nndir-directory defs))
  654.              server))
  655.        (unless (assq 'nndir-directory defs)
  656.          (push `(nndir-directory ,server) defs))
  657.        (push `(nndir-current-group
  658.            ,(file-name-nondirectory (directory-file-name nndir-directory)))
  659.          defs)
  660.        (push `(nndir-top-directory
  661.            ,(file-name-directory (directory-file-name nndir-directory)))
  662.          defs)
  663.        (nnoo-change-server 'nndir server defs))
  664.      
  665.      (nnoo-map-functions nndir
  666.        (nnml-retrieve-headers 0 nndir-current-group 0 0)
  667.        (nnmh-request-article 0 nndir-current-group 0 0)
  668.        (nnmh-request-group nndir-current-group 0 0)
  669.        (nnmh-close-group nndir-current-group 0))
  670.      
  671.      (nnoo-import nndir
  672.        (nnmh
  673.         nnmh-status-message
  674.         nnmh-request-list
  675.         nnmh-request-newgroups))
  676.      
  677.      (provide 'nndir)
  678. File: gnus,  Node: Score File Syntax,  Next: Headers,  Prev: Backend Interface,  Up: A Programmers Guide to Gnus
  679. Score File Syntax
  680. -----------------
  681.    Score files are meant to be easily parsable, but yet extremely
  682. mallable.   It was decided that something that had the same read syntax
  683. as an Emacs Lisp list would fit that spec.
  684.    Here's a typical score file:
  685.      (("summary"
  686.        ("win95" -10000 nil s)
  687.        ("Gnus"))
  688.       ("from"
  689.        ("Lars" -1000))
  690.       (mark -100))
  691.    BNF definition of a score file:
  692.      score-file       = "" / "(" *element ")"
  693.      element          = rule / atom
  694.      rule             = string-rule / number-rule / date-rule
  695.      string-rule      = "(" quote string-header quote space *string-match ")"
  696.      number-rule      = "(" quote number-header quote space *number-match ")"
  697.      date-rule        = "(" quote date-header quote space *date-match ")"
  698.      quote            = <ascii 34>
  699.      string-header    = "subject" / "from" / "references" / "message-id" /
  700.                         "xref" / "body" / "head" / "all" / "followup"
  701.      number-header    = "lines" / "chars"
  702.      date-header      = "date"
  703.      string-match     = "(" quote <string> quote [ "" / [ space score [ "" /
  704.                         space date [ "" / [ space string-match-t ] ] ] ] ] ")"
  705.      score            = "nil" / <integer>
  706.      date             = "nil" / <natural number>
  707.      string-match-t   = "nil" / "s" / "substring" / "S" / "Substring" /
  708.                         "r" / "regex" / "R" / "Regex" /
  709.                         "e" / "exact" / "E" / "Exact" /
  710.                         "f" / "fuzzy" / "F" / "Fuzzy"
  711.      number-match     = "(" <integer> [ "" / [ space score [ "" /
  712.                         space date [ "" / [ space number-match-t ] ] ] ] ] ")"
  713.      number-match-t   = "nil" / "=" / "<" / ">" / ">=" / "<="
  714.      date-match       = "(" quote <string> quote [ "" / [ space score [ "" /
  715.                         space date [ "" / [ space date-match-t ] ] ] ] ")"
  716.      date-match-t     = "nil" / "at" / "before" / "after"
  717.      atom             = "(" [ required-atom / optional-atom ] ")"
  718.      required-atom    = mark / expunge / mark-and-expunge / files /
  719.                         exclude-files / read-only / touched
  720.      optional-atom    = adapt / local / eval
  721.      mark             = "mark" space nil-or-number
  722.      nil-or-number    = "nil" / <integer>
  723.      expunge          = "expunge" space nil-or-number
  724.      mark-and-expunge = "mark-and-expunge" space nil-or-number
  725.      files            = "files" *[ space <string> ]
  726.      exclude-files    = "exclude-files" *[ space <string> ]
  727.      read-only        = "read-only" [ space "nil" / space "t" ]
  728.      adapt            = "adapt" [ space "nil" / space "t" / space adapt-rule ]
  729.      adapt-rule       = "(" *[ <string> *[ "(" <string> <integer> ")" ] ")"
  730.      local            = "local" *[ space "(" <string> space <form> ")" ]
  731.      eval             = "eval" space <form>
  732.      space            = *[ " " / <TAB> / <NEWLINE> ]
  733.    Any unrecognized elements in a score file should be ignored, but not
  734. discarded.
  735.    As you can see, white space is needed, but the type and amount of
  736. white space is irrelevant.  This means that formatting of the score
  737. file is left up to the programmer--if it's simpler to just spew it all
  738. out on one looong line, then that's ok.
  739.    The meaning of the various atoms are explained elsewhere in this
  740. manual.
  741. File: gnus,  Node: Headers,  Next: Ranges,  Prev: Score File Syntax,  Up: A Programmers Guide to Gnus
  742. Headers
  743. -------
  744.    Gnus uses internally a format for storing article headers that
  745. corresponds to the NOV format in a mysterious fashion.  One could
  746. almost suspect that the author looked at the NOV specification and just
  747. shamelessly *stole* the entire thing, and one would be right.
  748.    "Header" is a severely overloaded term.  "Header" is used in RFC1036
  749. to talk about lines in the head of an article (eg., `From').  It is
  750. used by many people as a synonym for "head"--"the header and the body".
  751. (That should be avoided, in my opinion.)  And Gnus uses a format
  752. internally that it calls "header", which is what I'm talking about
  753. here.  This is a 9-element vector, basically, with each header (ouch)
  754. having one slot.
  755.    These slots are, in order: `number', `subject', `from', `date',
  756. `id', `references', `chars', `lines', `xref'.  There are macros for
  757. accessing and setting these slots - they all have predictable names
  758. beginning with `mail-header-' and `mail-header-set-', respectively.
  759.    The `xref' slot is really a `misc' slot.  Any extra info will be put
  760. in there.
  761. File: gnus,  Node: Ranges,  Next: Group Info,  Prev: Headers,  Up: A Programmers Guide to Gnus
  762. Ranges
  763. ------
  764.    GNUS introduced a concept that I found so useful that I've started
  765. using it a lot and have elaborated on it greatly.
  766.    The question is simple: If you have a large amount of objects that
  767. are identified by numbers (say, articles, to take a *wild* example)
  768. that you want to callify as being "included", a normal sequence isn't
  769. very useful.  (A 200,000 length sequence is a bit long-winded.)
  770.    The solution is as simple as the question: You just collapse the
  771. sequence.
  772.      (1 2 3 4 5 6 10 11 12)
  773.    is transformed into
  774.      ((1 . 6) (10 . 12))
  775.    To avoid having those nasty `(13 . 13)' elements to denote a
  776. lonesome object, a `13' is a valid element:
  777.      ((1 . 6) 7 (10 . 12))
  778.    This means that comparing two ranges to find out whether they are
  779. equal is slightly tricky:
  780.      ((1 . 5) 7 8 (10 . 12))
  781.    and
  782.      ((1 . 5) (7 . 8) (10 . 12))
  783.    are equal.  In fact, any non-descending list is a range:
  784.      (1 2 3 4 5)
  785.    is a perfectly valid range, although a pretty long-winded one.  This
  786. is also legal:
  787.      (1 . 5)
  788.    and is equal to the previous range.
  789.    Here's a BNF definition of ranges.  Of course, one must remember the
  790. semantic requirement that the numbers are non-descending.  (Any number
  791. of repetition of the same number is allowed, but apt to disappear in
  792. range handling.)
  793.      range           = simple-range / normal-range
  794.      simple-range    = "(" number " . " number ")"
  795.      normal-range    = "(" start-contents ")"
  796.      contents        = "" / simple-range *[ " " contents ] /
  797.                        number *[ " " contents ]
  798.    Gnus currently uses ranges to keep track of read articles and article
  799. marks.  I plan on implementing a number of range operators in C if The
  800. Powers That Be are willing to let me.  (I haven't asked yet, because I
  801. need to do some more thinking on what operators I need to make life
  802. totally range-based without ever having to convert back to normal
  803. sequences.)
  804. File: gnus,  Node: Group Info,  Next: Emacs/XEmacs Code,  Prev: Ranges,  Up: A Programmers Guide to Gnus
  805. Group Info
  806. ----------
  807.    Gnus stores all permanent info on groups in a "group info" list.
  808. This list is from three to six elements (or more) long and exhaustively
  809. describes the group.
  810.    Here are two example group infos; one is a very simple group while
  811. the second is a more complex one:
  812.      ("no.group" 5 (1 . 54324))
  813.      
  814.      ("nnml:my.mail" 3 ((1 . 5) 9 (20 . 55))
  815.                      ((tick (15 . 19)) (replied 3 6 (19 . 3)))
  816.                      (nnml "")
  817.                      (auto-expire (to-address "ding@ifi.uio.no")))
  818.    The first element is the group name as Gnus knows the group; the
  819. second is the group level; the third is the read articles in range
  820. format; the fourth is a list of article marks lists; the fifth is the
  821. select method; and the sixth contains the group parameters.
  822.    Here's a BNF definition of the group info format:
  823.      info          = "(" group space level space read
  824.                      [ "" / [ space marks-list [ "" / [ space method [ "" /
  825.                      space parameters ] ] ] ] ] ")"
  826.      group         = quote <string> quote
  827.      level         = <integer in the range of 1 to inf>
  828.      read          = range
  829.      marks-lists   = nil / "(" *marks ")"
  830.      marks         = "(" <string> range ")"
  831.      method        = "(" <string> *elisp-forms ")"
  832.      parameters    = "(" *elisp-forms ")"
  833.    Actually that `marks' rule is a fib.  A `marks' is a `<string>'
  834. consed on to a `range', but that's a bitch to say in pseudo-BNF.
  835. File: gnus,  Node: Emacs/XEmacs Code,  Next: Various File Formats,  Prev: Group Info,  Up: A Programmers Guide to Gnus
  836. Emacs/XEmacs Code
  837. -----------------
  838.    While Gnus runs under Emacs, XEmacs and Mule, I decided that one of
  839. the platforms must be the primary one.  I chose Emacs.  Not because I
  840. don't like XEmacs or Mule, but because it comes first alphabetically.
  841.    This means that Gnus will byte-compile under Emacs with nary a
  842. warning, while XEmacs will pump out gigabytes of warnings while
  843. byte-compiling.  As I use byte-compilation warnings to help me root out
  844. trivial errors in Gnus, that's very useful.
  845.    I've also consistently used Emacs function interfaces, but have used
  846. Gnusey aliases for the functions.  To take an example:  Emacs defines a
  847. `run-at-time' function while XEmacs defines a `start-itimer' function.
  848. I then define a function called `gnus-run-at-time' that takes the same
  849. parameters as the Emacs `run-at-time'.  When running Gnus under Emacs,
  850. the former function is just an alias for the latter.  However, when
  851. running under XEmacs, the former is an alias for the following function:
  852.      (defun gnus-xmas-run-at-time (time repeat function &rest args)
  853.        (start-itimer
  854.         "gnus-run-at-time"
  855.         `(lambda ()
  856.            (,function ,@args))
  857.         time repeat))
  858.    This sort of thing has been done for bunches of functions.  Gnus does
  859. not redefine any native Emacs functions while running under XEmacs - it
  860. does this `defalias' thing with Gnus equivalents instead.  Cleaner all
  861. over.
  862.    Of course, I could have chosen XEmacs as my native platform and done
  863. mapping functions the other way around.  But I didn't.  The performance
  864. hit these indirections impose on Gnus under XEmacs should be slight.
  865. File: gnus,  Node: Various File Formats,  Prev: Emacs/XEmacs Code,  Up: A Programmers Guide to Gnus
  866. Various File Formats
  867. --------------------
  868. * Menu:
  869. * Active File Format::      Information on articles and groups available.
  870. * Newsgroups File Format::  Group descriptions.
  871. File: gnus,  Node: Active File Format,  Next: Newsgroups File Format,  Up: Various File Formats
  872. Active File Format
  873. ..................
  874.    The active file lists all groups that are available on the server in
  875. question.  It also lists the highest and lowest current article numbers
  876. in each group.
  877.    Here's an excerpt from a typical active file:
  878.      soc.motss 296030 293865 y
  879.      alt.binaries.pictures.fractals 3922 3913 n
  880.      comp.sources.unix 1605 1593 m
  881.      comp.binaries.ibm.pc 5097 5089 y
  882.      no.general 1000 900 y
  883.    Here's a pseudo-BNF definition of this file:
  884.      active      = *group-line
  885.      group-line  = group space high-number space low-number space flag <NEWLINE>
  886.      group       = <non-white-space string>
  887.      space       = " "
  888.      high-number = <non-negative integer>
  889.      low-number  = <positive integer>
  890.      flag        = "y" / "n" / "m" / "j" / "x" / "=" group
  891. File: gnus,  Node: Newsgroups File Format,  Prev: Active File Format,  Up: Various File Formats
  892. Newsgroups File Format
  893. ......................
  894.    The newsgroups file lists groups along with their descriptions.  Not
  895. all groups on the server have to be listed,  and not all groups in the
  896. file have to exist on the server.  The file is meant purely as
  897. information to the user.
  898.    The format is quite simple; a group name, a tab, and the description.
  899. Here's the definition:
  900.      newsgroups    = *line
  901.      line          = group tab description <NEWLINE>
  902.      group         = <non-white-space string>
  903.      tab           = <TAB>
  904.      description   = <string>
  905. File: gnus,  Node: Emacs for Heathens,  Next: Frequently Asked Questions,  Prev: A Programmers Guide to Gnus,  Up: Appendices
  906. Emacs for Heathens
  907. ==================
  908.    Believe it or not, but some people who use Gnus haven't really used
  909. Emacs much before they embarked on their journey on the Gnus Love Boat.
  910. If you are one of those unfortunates whom "`M-C-a'", "kill the region",
  911. and "set `gnus-flargblossen' to an alist where the key is a regexp that
  912. is used for matching on the group name" are magical phrases with little
  913. or no meaning, then this appendix is for you.  If you are already
  914. familiar with Emacs, just ignore this and go fondle your cat instead.
  915. * Menu:
  916. * Keystrokes::      Entering text and executing commands.
  917. * Emacs Lisp::      The built-in Emacs programming language.
  918. File: gnus,  Node: Keystrokes,  Next: Emacs Lisp,  Up: Emacs for Heathens
  919. Keystrokes
  920. ----------
  921.    * Q: What is an experienced Emacs user?
  922.    * A: A person who wishes that the terminal had pedals.
  923.    Yes, when you use Emacs, you are apt to use the control key, the
  924. shift key and the meta key a lot.  This is very annoying to some people
  925. (notably `vi'le users), and the rest of us just love the hell out of
  926. it.  Just give up and submit.  Emacs really does stand for
  927. "Escape-Meta-Alt-Control-Shift", and not "Editing Macros", as you may
  928. have heard from other disreputable sources (like the Emacs author).
  929.    The shift key is normally located near your pinky fingers, and are
  930. normally used to get capital letters and stuff.  You probably use it all
  931. the time.  The control key is normally marked "CTRL" or something like
  932. that.  The meta key is, funnily enough, never marked as such on any
  933. keyboards.  The one I'm currently at has a key that's marked "Alt",
  934. which is the meta key on this keyboard.  It's usually located somewhere
  935. to the left hand side of the keyboard, usually on the bottom row.
  936.    Now, us Emacs people doesn't say "press the meta-control-m key",
  937. because that's just too inconvenient.  We say "press the `M-C-m' key".
  938. `M-' is the prefix that means "meta" and "C-" is the prefix that means
  939. "control".  So "press `C-k'" means "press down the control key, and
  940. hold it down while you press `k'".  "Press `M-C-k'" means "press down
  941. and hold down the meta key and the control key and then press `k'".
  942. Simple, ay?
  943.    This is somewhat complicated by the fact that not all keyboards have
  944. a meta key.  In that case you can use the "escape" key.  Then `M-k'
  945. means "press escape, release escape, press `k'".  That's much more work
  946. than if you have a meta key, so if that's the case, I respectfully
  947. suggest you get a real keyboard with a meta key.  You can't live without
  948.